As an aside, I think we should remove LoadContext::path and just stick to supporting LoadContext::asset_path. It seems like a footgun to provide the std::path::Path since they don't work with custom asset soruces. If a user who needs the raw Path, they can just do context.asset_path().path().

That's for a future PR though.

Yes, please, kill it with fire!

Wow that random flake actually caught another issue! Apparently materials are doing their own load of the textures, but this load always just fetches the handle from the previous texture loads (since we're still holding those handles).

I've now checked to make sure there are no other joins so we shouldn't have any more of these issues.

As an aside, I don't think there's a need for us to be doing a second load for the materials. We should just propagate the texture handles through to these functions so they can get the texture handles that way. Having the loads just happen to call the same path seems incredibly brittle. Another PR though haha.

Edit: I looked into why we need a second load for the materials. The problem is that we only update the dependencies of a subasset if there is a load involved. If we just passed in the texture handles, we wouldn't get that load, so our material wouldn't have the texture as a dependency, meaning the is_loaded_with_dependencies check would be wrong. We should probably just be calling VisitDependencies in the load_context to solve this at some point.